Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: async callbacks #162

Draft
wants to merge 20 commits into
base: sc-feat/entrypoints
Choose a base branch
from
Draft

Conversation

0xDiscotech
Copy link

@0xDiscotech 0xDiscotech commented Dec 18, 2024

Callbacks PoC

This draft showcases a complete callback flow where a call originates on the origin chain, triggers execution on a destination chain, and then returns the result to the origin chain, where it is handled with custom logic.

The flow is as follows:
image

Possible Next Steps

  • Having a dedicated library to abstract functionality and facilitate the interaction would be a valuable addition to the ecosystem.

Possible Future Improvements

  • Flexible Callback Contexts: Introducing a more complex data structure to support features like expiration times or additional metadata.
  • Robust Error Handling: Supporting logic to handle both successful and failed callbacks.

Additional Context

@0xDiscotech 0xDiscotech marked this pull request as draft December 18, 2024 02:41
@0xDiscotech 0xDiscotech mentioned this pull request Dec 18, 2024
@ben-chain
Copy link

This is awesome! I did some hacking on something similar here a few weeks back. I'm curious, what is the motivation for having the entrypoint contract call occur earlier in the call stack than the CDM? Is it to preserve the CDM's cross domain context (sender, chainId, etc) or something else?

In terms of future work -- one thing I came to after hacking was that dependent async calls are probably an important feature. For instance, I suspect devs often will want to make an async call which gets relayed only after some other L2<>L2 Message (e.g. a SuperchainERC20 transfer), or create multiple async calls, and require that they be delivered in order.

@skeletor-spaceman
Copy link

I'm curious, what is the motivation for having the entrypoint contract call occur earlier in the call stack than the CDM? Is it to preserve the CDM's cross domain context (sender, chainId, etc) or something else?

yes! it's to keep the CDM as the "exitpoint" of the relayed messages, abstracting away the extra logic handled via the "wrapper" entrypoint contract

In terms of future work -- one thing I came to after hacking was that dependent async calls are probably an important feature. For instance, I suspect devs often will want to make an async call which gets relayed only after some other L2<>L2 Message (e.g. a SuperchainERC20 transfer), or create multiple async calls, and require that they be delivered in order.

this is exactly why we build the entrypoint primitive!
here is the draft idea (Design 2 is the way to go imho): https://gist.github.com/0xParticle/5119cfa271a6fba6ae8b7649e0bba5db

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants